Project structure
The separation of platform and business logic is solved by organizing classes into the appropriate layers of the application – the user-developed layer and the metadata layer.
Between these levels, in the platform architecture, there are channels for managing the interface and managing data.
The following assembly naming convention has been adopted:
C1 – WinForms components from GrapeCity
C2 – platform system components
C3 – assemblies related to the applied solution being developed
Visual Studio Solution Structure
The application is built from two groups of libraries:
- Libraries developed by the user and containing business logic.
- Libraries created by the Designer based on the metadata structure using class generation processing.
Here, for example, the libraries developed by the user:
- C3.Accounting.Module — object modules and conduction modules
- C3.Accounting.Win — forms of objects (directories, documents, reports and processings)
Libraries created by Designer:
- C3.JustMoney.Model — applied objects (directories, documents, registers)
- C3.ModelManager — model application object access manager
- C3.ModuleManager — application object module access manager
- C3.JustMoney.Form — base classes of forms of applied objects
- C3.FormManager — application object form manager
JustMoney, Accounting, Docflow – business logic name, can be anything..
The composition of the solution libraries depends on their following functionality:
Configuration data schema model (catalogs, documents, registers)
In the configuration structure, the most generalized element is the schema.
Inside each scheme there are objects of the configuration model (catalogs, documents, etc.).
An important feature is the presence of relationships between objects within the schema, at the database level using Foreign Keys. But objects in different schemes do not have this ability.
This approach allows you to build a multi-service data architecture in one configuration, distributing the development / support of schemes between different development teams.
Model assemblies “C3.JustMoney.Model” или “C3.JustMoney.Data”, “C3.XXX.Model”
- Generated by Designer
- Includes all configuration data objects as classes (catalogs, documents, registers)
- Through these classes, modification of data in the database is performed
- A configuration can contain multiple schemas. This feature allows you to update, upload, download each scheme independently
Model managers (catalogs, documents, registers)
When developing an applied solution, the developer works with model objects, for example, the “Contractor” directory or the “Invoice” document.
Accordingly, the model objects accept the same types as field values, and not identifiers and other simple types of the programming language, for example, “Invoice.Contractor = Buyer”, where “Buyer” is an instance of the “Contractor” type.
The construction of applied model types takes place in the model manager.
Сборка “C3.ModelManager” или “C3.DataManager”.
- Generated by Designer
- Includes data access managers. Managers return instances of classes of catalogs, documents
- Through instances of the classes of catalogs and documents (from the assembly of the model C3.JustMoney.Model, C3.XXX.Model), the data in the database is modified
Base classes of forms of configuration elements
- Generated by Designer
- The assembly includes the base classes of the forms of the elements of all objects in all configuration schemes (catalogs, documents, registers)
- User forms in C3.Accounting.Win, C3.XXX.Win libraries are inherited from these base classes
Form base class library “C3.JustMoney.Form”, “C3.XXX.BaseForm”.
Managers of forms (catalogs, documents, reports, processings)
- Generated by Designer
- Includes access managers to object forms (forms of elements, lists). The form manager returns form class instances from custom modules (C3.Accounting.Win, C3.XXX.Win)
- Form data is displayed in the application’s MDI window
Assembly “C3.FormManager”.
Manager of object modules and conduction modules
The framework provides guaranteed execution of predefined methods in object modules and rendering modules when writing or rendering object instances, regardless of the application context, windows application or web application.
Examples of such predefined methods are BeforeWrite, AfterWrite, Post, UnPost, and so on.
The use of such methods can be compared with triggers in databases, but with advanced features, for example, contacting a third-party service in such a method or calculating totals, and for some reason aborting a transaction, and much more that is impossible in a database trigger.
Assembly “C3.ModuleManager”.
- Generated by Designer
- Includes managers for accessing object modules and holding from user libraries C3.Accounting.Module, C3.XXX.Module